fix: type GeneralNameJson.value as string or directory name JSON - #540

Please revise the JSON typing approach before merging. I would like to keep this update compatible with the existing API and provide a complete typed representation.

There are two issues with the current change:

1. string | RelativeDistinguishedNamesJson does not describe all toJSON() results. For example, iPAddress returns ASN.1 JSON without typesAndValues. The narrowing used by the new consumer test (typeof json.value !== "string") therefore does not identify a directory name; the proposed type would allow reading json.value.typesAndValues.length for an IP address, which would fail at runtime. The other ASN.1 object variants must also be covered.
2. Widening the existing value type breaks TypeScript compatibility, even for consumers of string variants. For example, this previously valid assignment stops compiling although its runtime value is still a string:

const email: string = new GeneralName({
  type: 1,
  value: "alice@example.com"
}).toJSON().value;

Please consider extending the existing result with an optional typedValue field instead, preserving the current runtime values and declarations of type and value:

interface GeneralNameJson {
  type: number;
  value: string; // Keep the legacy declaration for compatibility.
  typedValue?: GeneralNameTypedValue;
}

The optional field preserves compatibility with existing object literals, stored JSON from earlier versions, and implementations that already return GeneralNameJson:

const json: GeneralNameJson = {
  type: 2,
  value: "example.com"
};

For a valid DNS name, the extended result would be:

{
  "type": 2,
  "value": "example.com",
  "typedValue": {
    "kind": "dNSName",
    "value": "example.com"
  }
}

GeneralNameTypedValue should be a complete discriminated union with its own kind field. These are suggested shapes for the new typedValue field only; retain the full existing value in each case:

A few details to account for:

• otherName payloads depend on the OID, so the general representation should retain the BER of the payload rather than assume a particular decoded shape.
• For x400Address, retaining the BER of the original GeneralName ASN.1 node is sufficient; a complete X.400 object model need not be introduced here.
• The directory-name attributes are a convenient projection; retain their OIDs and ASN.1 types, and keep the full legacy representation in value.
• nameAssigner is optional for ediPartyName. Please also check the schema-parsing path: it currently reads asn1.result.ediPartyName, but that name is not assigned in the schema. Do not produce a typed representation from missing data.
• For IP addresses, cover IPv4, IPv6, and the address-and-mask form used in NameConstraints, retaining the original bytes.

Consumers could then use:

const typed = name.toJSON().typedValue;

if (typed?.kind === "directoryName") {
  console.log(typed.attributes);
}

if (typed?.kind === "iPAddress") {
  console.log(typed.address);
}

If a correct typed representation cannot be produced, omit typedValue and preserve the existing behavior of toJSON() rather than introduce new exceptions.

This can be treated as a minor addition if the JSON contract permits additional fields. The output of JSON.stringify() will change, so consumers requiring an exact JSON shape need to be considered. Correcting the existing, imprecise value declaration can be reserved for a future major release.